1. Field of the Invention
The present invention relates to a network device, system and method for providing a list of controlled devices, and more particularly, to a network device, system and method for providing a list of controlled devices, wherein each of the controlled devices connected in a network has a list of other controlled devices, and upon receipt of a message searching for a specific controlled device from a control point, the controlled device can transmit a response message to the control point on behalf of the specific controlled device.
2. Description of the Related Art
Generally, a home network is constructed of a private network based on the Internet protocol (IP) and controls a variety of equipment, such as all types of personal computers, intelligent products and wireless apparatus used indoors at home, by connecting them in a single network.
As for a home network method, there has been proposed a method wherein a common virtual computing environment called ‘middleware’ is established with respect to equipment existing in a private network and applications are then provided to the middleware. The middleware enables communication among the various kinds of equipment in a home network. As for such middleware, Home AV Interoperability (HAVI), Universal Plug and Play (UPnP), Jini, and Home Wide Web (HWW) have been proposed up to now.
Various pieces of equipment existing in a home network are connected to one another through such home network middleware via a Peer-to-Peer type network, and each piece of equipment uses an IP address that is assigned by a dynamic host configuration protocol (hereinafter, referred to as “DHCP”) server or selected by an automatic IP designating function (Auto IP).
Namely, when initially connected to a home network, each piece of equipment searches for the DHCP server, and acquires an address assigned depending on the response from the DHCP server or automatically selects an IP address within a predetermined range by using Auto IP in case of a network in which a DHCP server is not running.
Such equipment using an IP address assigned by the DHCP server or selected by Auto IP communicates with the other equipment in the network by using Transmission Control Protocol/Internet Protocol (TCP/IP) and can be searched for and referred to in the network through the IP address.
Further, in home network middleware such as UPnP, a protocol such as Simple Service Discovery Protocol (hereinafter, referred to as “SSDP”) is used as a method of searching for equipment existing in the home network. Here, the SSDP can be roughly divided into two types: a multicast search (M-Search) message for use in searching for a given type of controlled device (hereinafter, referred to as “CD”) desired by a control point (hereinafter, referred to as “CP”), and a notify message used when a CD notifies its own state. As for the notify message, there are a Notify Alive message sent after a CD is connected to a network and assigned its own IP, and a Notify Byebye message sent when a CD is normally removed from the network. Namely, if a CD is connected to a network, the CD is assigned an IP address by the DHCP server or in an Auto-IP manner and then sends a Notify Alive message via user datagram protocol (UDP) multicast in order to notify that the CD has been added to the network. However, since the CD does not know whether a UDP packet is properly delivered, the CD repeatedly transmits the same Notify Alive message to the same multicast addresses several times.
Furthermore, if a CP receives a command to perform a specific service from a user or an application, the CP creates a multicast search message to search for a given type of CD necessary for performing a relevant service and transmits the multicast search message via UDP multicast. Similarly to the situation just discussed in regard to the DC repeatedly transmitting a Notify Alive message, according to UDP multicast, since the CP does not know the delivery state of the transmitted multicast search message, the CP repeatedly transmits the same multicast search message to the same multicast addresses more than one time.
Moreover, a CD that has received a multicast search message transmitted from the CP makes and transmits a multicast search response message to the CP if the type of the CD conforms to the type requested by the CP. Then, the CP collects response messages to its transmitted multicast search message, selects a specific CD and stores information with respect to the selected CD in a cache of the CP itself, if necessary. Thereafter, the CP can control the CD necessary for performing a relevant service through collected CD information and CD information stored in its cache.
In the meantime, if a CD is normally removed from the network, the CD first makes a Notify Byebye message and transmits the message via UDP multicast. Then, the CP that has received the message deletes the relevant CD information stored in its cache.
FIG. 1 is a view showing an operation process of controlling UPnP controlled devices existing in a home network of the related art. Control points CP1-CP3 perform respective discovery processes for searching for a device connected to the network in order to use a desired service. Each discovery process employs a multicast search method for transferring a multicast packet to all devices connected to the network. According to the UDP method used, however, it is impossible to confirm whether the multicast packet has been received.
First, if CPs 2000 to 2200 perform respective discovery processes of searching for desired devices, CDs 1000 to 1500, which are connected to the network transmit response messages as device packets. However, a multicast search message for finding CDs 1000 to 1500 transmitted from CP2 2100 may not be delivered to CD2 1100, or CD3 1200 that has received the multicast search message may not be able to transmit a multicast search response message to CP2 2100 while the relevant packet is lost. In this case, CP2 2100 fails to find a relevant CD.
FIG. 2 is a view showing a case where the control point does not receive a response message 100, which has been sent by the controlled device CD2 (1100), to the device packet transmitted from the control point CP1 (2000) in the home network of the related art. FIG. 3 is a view showing a case where the controlled device CD2 (1100) does not receive the device packet 200 transmitted from the control point CP1 (2000) in the home network of the related art.
FIG. 4 is a view showing a case where the control point CP1 (2000) does not know the state of a controlled device CD1 (1000) abnormally removed in the home network of the related art. If CDs 1000 to 1200 are normally removed from the network, CDs 1000 to 1200 prepare their Notify Byebye messages and transmit them via UDP multicast. Then, CP 2000 that has received the Notify Byebye message deletes information on the relevant CDs from its cache 2010. Thus, a CP can recognize that relevant CDs do not exist in the network.
However, in a case where any one of CDs 1000 to 1200, which has been connected and operated, abnormally stops its operation, the CD cannot transmit a Notify Byebye message and, thus, it is incorrectly recognized by the cache 2010 of CP 2000 that the relevant CD is still alive. Such incorrect cache information remains until the duration of the CD recorded together with the information in the cache 2010 of the CP 2000 elapses. Namely, since the UPnP discovery mechanism can know CD information remaining in the cache only through a Notify Alive message or a Notify Byebye message sent by a relevant CD, there is no way to inform the CPs of such abnormal removal of a relevant CD if the relevant CD is abnormally terminated.
Therefore, there is a need for a method and device, wherein CDs connected to a UPnP network can multicast notify messages to mutually inform the states of the CDs themselves, or it is possible to solve a cache coherence problem that a relevant CD is recognized to operate due to the duration thereof remaining in the cache of CP 2000, even in a case where the relevant CD abnormally ceases operation.